Глава 2. Клиент-серверный вариант работы

«1С:Предприятие» позволяет работать с информационными базами в варианте клиент-сервер. В случае «1С:Предприятия» под вариантом клиент-сервер понимается архитектура, подразумевающая наличие следующих программных уровней:

● один из видов клиентского приложения «1С:Предприятия» (обычный клиент, тонкий клиент или веб-клиент);

● веб-сервер (только для веб-клиента и для тонкого клиента, подключенного через веб-сервер);

● кластер серверов «1С:Предприятия»;

● сервер баз данных.

На рис.1 показана схема взаимодействия элементов системы.

Рис. 1. Схема взаимодействия элементов системы

Клиентские приложения, тонкие клиенты и веб-клиенты – это и есть «1С:Предприятие» (в различных режимах запуска), с которым работает конечный пользователь. Для работы веб-клиента требуется только веб-браузер.

Кластер серверов «1С:Предприятия» является логическим понятием и представляет собой совокупность рабочих серверов, функционирующих на одном или нескольких компьютерах, и списка информационных баз, которые размещены в этом кластере.

Кластер серверов «1С:Предприятия» образует промежуточный программный слой между клиентским приложением и сервером баз данных. Клиентские приложения не имеют непосредственного доступа к серверу баз данных. Для доступа к информационной базе клиентское приложение взаимодействует с кластером серверов «1С:Предприятия».

Архитектура системы ориентирована на максимальный перенос выполнения всей функциональности на кластер серверов и максимальное «облегчение» клиента. В кластере серверов выполняется вся работа прикладных объектов, выполняется подготовка к отображению форм (чтение объектов из информационной базы и заполнение данных формы, расположение элементов, запись данных формы после изменения) и командного интерфейса, формируются отчеты. На клиенте выполняется только отображение информации, подготовленной в кластере серверов, выполняется взаимодействие с пользователем и вызовы серверных методов для выполнения необходимых действий.

Кроме того, на серверах, входящих в кластер серверов «1С:Предприятия», хранятся файлы, содержащие журналы регистрации информационных баз, зарегистрированных на данном сервере «1С:Предприятия», и другие служебные файлы. Все эти данные не являются жизненно необходимыми для работы с информационными базами, и их потеря не приведет к неработоспособности информационных баз. Также на серверах, входящих в кластер, выполняются фоновые задания.

Установка кластера серверов «1С:Предприятия» выполняется программой установки «1С:Предприятия». Настройка кластера серверов выполняется с помощью утилиты администрирования кластера серверов, входящей в комплект поставки.

Ключ аппаратной защиты кластера серверов «1С:Предприятия» не является сетевым, поэтому он должен быть подключен к каждому компьютеру, на котором функционируют рабочие процессы кластера.

Веб-сервер необходим для работы веб-клиента и одного из вариантов работы тонкого клиента. Фактически в случае работы через веб-сервер с кластером серверов взаимодействует именно веб-сервер. А уже веб-сервер взаимодействует с тонким и веб-клиентами.

Примечание. Если явно не оговорено обратное, далее под термином «клиентское приложение» понимается обычный клиент, тонкий клиент или веб-сервер.

Сервер баз данных. Хранение жизненно важных данных информационных баз «1С:Предприятия» в варианте клиент-сервер обеспечивается сервером баз данных. В качестве сервера баз данных в «1С:Предприятии» могут использоваться различные СУБД (см. здесь). При этом каждая информационная база целиком сохраняется в отдельной базе данных используемой СУБД.

Основной единицей кластера серверов выступает рабочий сервер. Рабочий сервер – это компьютер, на котором выполняется агент сервера (ragent). Агент сервера «представляет» рабочий сервер в кластере серверов. Как правило, на одном компьютере располагается один рабочий сервер, однако в некоторых случаях (например, для целей отладки) возможна работа на одном физическом компьютере нескольких рабочих серверов. Рабочие серверы, расположенные на одном компьютере, должны иметь разные номера сетевых портов, идентифицирующих рабочий сервер, и работать с разными каталогами данных кластера.

Совет. Не рекомендуется размещать несколько рабочих серверов на одном физическом компьютере для систем, находящихся в промышленной эксплуатации.

Кластер серверов представляет собой один или несколько рабочих серверов. При этом информация о том, сколько рабочих серверов выполняется на одном физическом компьютере, не важна для описания и работы кластера. Для того чтобы «знать», для каких кластеров серверов данный рабочий сервер является центральным, агент сервера ведет список кластеров. Список кластеров представляет собой файл 1cv8wsrv.lst, в котором хранится информация о тех кластерах серверов, в состав которых входит данный рабочий сервер, а также список администраторов данного рабочего сервера. Данный файл хранится в каталоге данных кластера (см. здесь). Фактически, агент сервера не входит в состав рабочего сервера, а лишь обеспечивает его работу (в том числе и «представительство» в кластере серверов).

Рис. 2. Общая схема сервера «1С:Предприятия»

В состав любого кластера должен входить минимум один рабочий сервер, у которого установлено свойство Центральный сервер. Максимальное количество центральных серверов не ограничено. Это означает, что для всех рабочих серверов, входящих в состав кластера серверов, можно установить флажок Центральный сервер. Рабочий сервер может быть центральным сервером в одном кластере и обычным (не центральным) – в другом кластере серверов. Также, рабочий сервер с установленным признаком Центральный сервер, может выступать в качестве точки подключения к кластеру серверов, в состав которого он (рабочий сервер) входит.

Рабочая часть рабочего сервера включает в себя менеджер кластера (rmngr) и рабочий процесс (rphost). Менеджер кластера обеспечивает функционирование рабочего сервера и взаимодействие с другими рабочими серверами, входящими в состав кластера. Рабочий процесс непосредственно обслуживает клиентские приложения, взаимодействует с сервером баз данных, исполняет код, который в прикладном решении отмечен как выполняемый на сервере. Количество рабочих процессов определяется настройками рабочего сервера, кластера серверов и физическими характеристиками компьютера, на котором работает рабочий сервер.

В состав рабочего сервера может входить минимум один менеджер кластера. Если менеджер кластера работает на центральном сервере, то он называется главным менеджером кластера. Максимальное количество менеджеров кластера равно количеству сервисов кластера (см. здесь). Однако если один рабочий сервер входит в состав нескольких кластеров, то для каждого кластера будет создан минимум один менеджер кластера.

Главный менеджер кластера «ведет» реестр кластера. Реестр кластера представляет собой файл 1cv8clst.lst, который хранит следующую информацию:

● список информационных баз, зарегистрированных в данном кластере;

● список рабочих серверов, входящих в кластер;

● список рабочих процессов, входящих в кластер;

● список менеджеров кластера;

● список сервисов кластера;

● список администраторов кластера.

Если в состав кластера входит несколько центральных серверов, то реестр кластера ведется каждым из главных менеджеров кластера. Для того чтобы данные каждой копии реестра кластера были актуальными, внутри кластера серверов выполняется постоянная синхронизация реестра кластера между главными менеджерами кластера центральных серверов.

В самом простом случае, рабочий сервер и кластер серверов могут располагаться на одном компьютере, как показано на рис.3.

Рис. 3. Простой вариант кластера

Взаимодействие различных процессов кластера серверов «1С:Предприятия» между собой и с клиентским приложением осуществляется по протоколу TCP/IP. Таким образом, каждый из процессов кластера адресуется именем рабочего сервера, на котором он запущен, и номером сетевого порта.

По умолчанию при установке кластера серверов используются следующие номера сетевых портов:

● Агент сервера – порт 1540;

● Менеджер кластера – порт 1541.

● Для рабочего процесса номер порта выделяется динамически из указанного диапазона, по умолчанию используется диапазон сетевых портов 1560:1591.

При необходимости можно изменить номера и диапазон используемых портов.

Рис. 4. Простой кластер

На приведенном рисунке имя центрального сервера – 1C_Serv. Таким образом, сам центральный сервер адресуется как 1С_Serv:1540. Кластер, расположенный на этом сервере, адресуется как 1С_Serv:1541, а рабочий процесс – 1С_Serv:1561.

Когда клиентское приложение пытается подключиться к информационной базе в варианте клиент-сервер, оно обращается по адресу кластера серверов: 1С_Serv:1541.

Рис. 5. Обращение к простому кластеру

Менеджер кластера выбирает рабочий процесс, который будет обслуживать клиентское приложение, и сообщает клиентскому приложению его адрес. В данном случае, поскольку рабочий процесс один, это будет 1С_Serv:1561.

Рис. 6. Установленное соединение

Клиентское приложение связывается с выделенным ему рабочим процессом, который выполняет аутентификацию пользователя информационной базы и осуществляет все дальнейшее взаимодействие клиентского приложения с информационной базой.

ВНИМАНИЕ! Для функционирования системы версии клиентского приложения и сервера должны быть полностью идентичными. Функционирование системы будет невозможно, если, например, сервер имеет версию 8.3.3.100, а клиентское приложение – версию 8.3.3.150.

Вся функциональность менеджера кластера серверов разделена на несколько независимых сервисов. Каждый сервис обладает некоторыми характеристиками. Далее приведен список сервисов, с кратким описанием и указанием состава характеристик:

В таблице использованы следующие термины:

● Диск – ресурсоемкий сервис, создает повышенную нагрузку на дисковую подсистему.

● Память – ресурсоемкий сервис, создает повышенную нагрузку на процессор и оперативную память.

● Репликация – поддерживается репликация между основным и резервными экземплярами сервиса. Репликация возникает в том случае, если уровень отказоустойчивости кластера отличен от 0 (см. здесь). Для сервисов конфигурации кластера и блокировок кластера, репликация возникает в том случае, если в кластере зарегистрировано несколько рабочих серверов с установленным признаком Центральный сервер.

● Деление по ИБ – для каждой информационной базы существует свой экземпляр сервиса.

● Возможность переноса между рабочими серверами:

● Перенос+ – сервис может мигрировать между рабочими серверами без потери данных.

● Перенос– – сервис может мигрировать между рабочими серверами с потерей данных.

● Не переносится – сервис не может мигрировать между рабочими серверами и размещается только на компьютере центрального сервера кластера. Для таких сервисов не могут быть созданы требования назначения функциональности (см. здесь).

Сервисы кластера по типам сервисов, информационным базам и сеансам равномерно распределяются по рабочим серверам кластера.

Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя. Активным пользователем может являться:

● экземпляр клиентского приложения «1С:Предприятия»;

● экземпляр веб-приложения, в котором исполняется веб-клиент;

● экземпляр внешнего соединения (полученный из объекта V83.COMConnector);

● один экземпляр фонового задания;

● одно обращение к Web-сервису.

Сеансы могут быть активными и спящими. Одно из назначений спящего сеанса – сохранение работоспособности клиентского приложения после перехода клиентского компьютера в различные режимы энергосбережения. Сеанс переходит в спящее состояние в двух случаях:

● При нештатном разрыве соединения, назначенного сеансу (для толстого клиента, внешнего соединения, тонкого клиента при прямом соединении с сервером). При физическом отключении сети сервер обнаруживает разрыв соединения с клиентским приложением в течение 2-3 минуты.

● По истечении интервала времени, в течение которого клиентское приложение, использующее сеанс, не проявляется активности (для веб-клиента и тонкого клиента при подключении через веб-сервер). Если компьютер клиента не находится в режиме энергосбережения, и клиентское приложение бездействует (не выполняет никаких действий пользователя), то оно периодически вызывает сервер «1С:Предприятия» с интервалом 5-10 минут для поддержания активности сеанса. Поэтому не рекомендуется устанавливать время засыпания сеанса меньше 10 минут.

Любая активность клиентского приложения, использующего сеанс, приводит к пробуждению сеанса. Спящий сеанс завершается в следующих случаях:

● По истечении интервала времени, который определяет время жизни спящего сеанса.

● Если блокировки, установленные спящим сеансом, конфликтуют с блокировками, которые пытаются установить активные сеансы.

Сеанс, который переходит в спящее состояние, освобождает занятую им клиентскую лицензию. При активизации спящего сеанса он пытается получить клиентскую лицензию (если до перехода в спящий режим сеанс занимал клиентскую лицензию). Невозможность получения лицензии приводит к невосстановимому исключению и завершению сеанса.

Время перевода пассивного сеанса в спящее состояние и время, по истечении которого спящий сеанс будет завершен, задается в диалоге настройки параметров информационной базы, которые редактируются с помощью конфигуратора. Подробное описание диалога редактирования параметров информационной базы см. здесь.

Все данные, хранимые кластером, которые относятся к одному активному пользователю и актуальны только на время работы этого пользователя, являются данными сеанса. К данным сеанса относятся:

● информационная база,

● номер сеанса,

● аутентифицированный пользователь информационной базы,

● язык интерфейса,

● значения параметров сеанса,

● временные хранилища,

● статистика работы сеанса,

● информация форм управляемого приложения,

● некоторые внутренние данные платформы.

Данные сеансов сохраняет менеджер кластера. Для этого предусмотрен сервис сеансовых данных (см. здесь). При перезапуске кластера серверов данные сеансов сохраняются. Если активный пользователь не выполнил ни одного обращения к кластеру за определенный интервал времени и сеанс не назначен соединению, то сеанс переводится в спящее состояние. Интервал времени неактивности настраивается в параметрах информационной базы (в конфигураторе). Значение по умолчанию равно 1200 секунд. Для поддержания сеанса тонкий клиент и веб-клиент обеспечивают обращение к кластеру не реже 1 раза в 10 минут. Для ускорения доступа данные сеансов кешируются в рабочих процессах и в толстых клиентах. В списке активных пользователей показывается список активных сеансов.

Изменения данных сеанса, выполненные за время одного вызова сервера, хранятся в рабочем процессе и передаются менеджеру кластера только при возврате управления клиенту, как штатного, так и в результате программного исключения.

Изменения данных сеанса не сохраняются в менеджере кластера, если:

● в процессе вызова сервера аварийно завершился рабочий процесс;

● при возврате управления клиенту произошла ошибка передачи данных.

Соединение является средством доступа сеансов к кластеру серверов «1С:Предприятия», содержит ограниченное множество данных соединения, не отождествляется с активным пользователем. Также соединения используются для взаимодействия процессов кластера.

Для обращения клиента к кластеру сеанс назначается соединению. Все время, пока клиент не выполняет обращений к кластеру, сеанс может быть не назначен никакому соединению.

Разные варианты использования «1С:Предприятия» по-разному работают с сеансами и соединениями.

● Конфигуратор и толстый клиент:

● при старте: устанавливает соединение, начинает сеанс и назначает его соединению;

● при завершении: отменяет назначение сеанса соединению, заканчивает сеанс и разрывает соединение.

● Одно обращение к Web-сервису и одно выполнение фонового или регламентного задания:

● в начале обращения: выбирает соединение из пула, создает сеанс и назначает его соединению;

● в конце обращения: отменяет назначение сеанса соединению, заканчивает сеанс и возвращает соединение в пул.

● Тонкий клиент и веб-клиент начинают сеанс при старте и заканчивают сеанс при завершении:

● в начале обращения к кластеру выбирается соединение из пула, и ему назначается сеанс данного клиента.

● в конце обращения к кластеру назначение сеанса соединению отменяется, и соединение возвращается в пул.

Информация о сеансах отражается:

● в журнале регистрации,

● консоли кластера,

● средствах программного администрирования,

● технологическом журнале,

● глобальном контексте.

Администратор кластера может получить список существующих сеансов как для всего кластера, так и в разрезе информационных баз. Для этого утилита администрирования кластера и средства программного администрирования имеют соответствующие возможности.

Администратор кластера может закончить сеанс принудительно при помощи утилиты администрирования кластера и средств программного администрирования. При этом работа активного пользователя завершится аварийно. Если удаляется сеанс, назначенный соединению, то происходит разрыв этого соединения.

Администратор кластера с помощью утилиты администрирования и средств программного администрирования может установить блокировку установки сеансов, которая не позволяет начинать новые сеансы, но при этом не препятствует работе существующих сеансов.

Можно выделить два вида соединений:

● соединения с информационной базой,

● служебные соединения с рабочими процессами кластера.

Соединения с информационной базой имеют следующие отличительные особенности:

● соединение выполняется с конкретной информационной базой кластера;

● в таком соединении может выполняться код на встроенном языке;

● соединение может переустанавливаться с течением времени;

● соединение может быть разорвано принудительно командой консоли кластера или средствами встроенного языка;

● наличие соединений с информационной базой у рабочего процесса кластера препятствует остановке и запуску этого рабочего процесса.

Возможны следующие виды соединений с информационной базой:

● Толстый клиент,

● Тонкий клиент,

● Конфигуратор,

● Модуль расширения веб-сервера,

● COM-соединение,

● Фоновое задание.

Толстый клиент

Представляет собой соединение толстого клиента с информационной базой. Это соединение предназначено для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы.

Соединение Толстый клиент создается в результате интерактивного запуска толстого клиента в режиме 1С:Предприятие или в результате подключения к информационной базе с использованием технологии Automation Client/Server, например:

// Создать Automation сервер 1С:Предприятия
AutomationCервер = Новый COMОбъект("V83.Application");
// Установить соединение с информационной базой
// TestBase в кластере 1541 центрального сервера TestSrv
AutomationCервер.Connect("Srvr="TestSrv";Ref="TestBase");

Тонкий клиент

Представляет собой соединение тонкого клиента с информационной базой. Это соединение предназначено для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы.

Соединение Тонкий клиент создается в результате интерактивного запуска тонкого клиента или в результате подключения к информационной базе с использованием технологии Automation Client/Server, например:

// Создать Automation сервер 1С:Предприятия
AutomationCервер = Новый COMОбъект("V83С.Application");
// Установить соединение с информационной базой
// TestBase в кластере 1541 центрального сервера TestSrv
AutomationCервер.Connect("Srvr="TestSrv";Ref="TestBase");

Конфигуратор

Представляет собой соединение конфигуратора с информационной базой. Это соединение предназначено для создания и модификации конфигурации информационной базы и для выполнения административных и регламентных действий.

Модуль расширения веб-сервера

Представляет собой соединение веб-сервера с рабочим процессом сервера. Это соединение предназначено для работы веб-клиента, интернет-сервисов, а также тонкого клиента (по протоколу HTTP).

Соединение создается в момент обращения к интернет-сервису или при обращении веб-клиента или тонкого клиента (по протоколу HTTP) к серверу «1С:Предприятия». Соединение существует до перезапуска веб-сервера или до тех пор, пока соединение находится в пуле соединений модулей расширений веб-сервера (пока не закончится время жизни соединения в пуле, или пока данное соединение не будет вытеснено из пула другими соединениями).

Подробнее об интернет-сервисах см. здесь.

COM-соединение

Представляет собой соединение процесса, использующего функциональность внешнего соединения «1С:Предприятия», с информационной базой. Это соединение предназначено для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы.

COM-соединение создается в результате подключения к информационной базе с использованием технологии COM, например:

// Создать Automation сервер 1С:Предприятия
COMСоединитель = Новый COMОбъект("V83.COMConnector");
// Установить соединение с информационной базой
// TestBase в кластере 1541 центрального сервера TestSrv
СоединениеСИнформационнойБазой = COMСоединитель.Connect("Srvr="TestSrv";Ref="TestBase");

Фоновое задание

Представляет собой соединение рабочего процесса кластера с информационной базой. Это соединение предназначено для выполнения кода процедуры фонового задания.

Соединение фонового задания создается в случае:

● Получения платформой списка регламентных заданий, зарегистрированных в информационной базе;

● Запуска платформой зарегистрированного в информационной базе регламентного задания;

● Запуска фонового задания на выполнение из встроенного языка;

● Фонового исполнения отчета,

● Фонового поиска по подстроке,

● Фонового запроса списка,

● Запуска фоновой реструктуризации.

В частности, запуск фонового задания может выполняться разработчиком, средствами встроенного языка, например:

// Выполнить фоновое задание, описанное в процедуре
// ОбновлениеИндексаПолнотекстовогоПоиска
// общего модуля РегламентныеПроцедуры
ФоновоеЗадание = ФоновыеЗадания.Выполнить("РегламентныеПроцедуры.ОбновлениеИндексаПолнотекстовогоПоиска");

Соединение фонового задания существует до тех пор, пока существует контекст исполняемой процедуры фонового задания. После того как процедура выполнена или отчет сформирован, соединение фонового задания закрывается.

Подробнее о фоновых заданиях см. здесь. Подробнее о фоновом исполнении отчетов см. здесь.

Служебные соединения имеют следующие отличительные особенности:

● соединение выполняется с рабочим процессом и не ассоциируется с конкретной информационной базой;

● в служебных соединениях код на встроенном языке не выполняется;

● соединение не может быть разорвано принудительно, оно создается и завершается системой;

● наличие служебных соединений не препятствует остановке и запуску рабочих процессов кластера серверов.

Возможны следующие виды служебных соединений:

● Планировщик заданий,

● Отладчик,

● Консоль кластера,

● Сервер администрирования,

● COM-администратор,

● Системное фоновое задание.

Планировщик заданий

Представляет собой соединение планировщика заданий с рабочим процессом. Это соединение предназначено для управления работой фоновых заданий, в том числе для запуска регламентных заданий по расписанию. Данное соединение также используется для других случаев обращения менеджера кластера (rmngr) к рабочему процессу (rphost), например, при получении списка сеансов.

Соединение планировщика заданий создается при первом запуске фонового задания. Оно может порождать соединение фонового задания с информационной базой в том же рабочем процессе кластера серверов. После завершения соединения фонового задания соединение планировщика заданий не завершается, а существует до тех пор, пока рабочий процесс кластера не будет выключен или удален.

Подробнее о фоновых заданиях см. здесь.

Отладчик

Представляет собой соединение отладчика с рабочим процессом кластера, находящимся в режиме отладки. Это соединение предназначено для управления ходом отладки и поиском предметов отладки, имеющихся в настоящий момент.

Соединение отладчика создается при подключении предмета отладки или при поиске предметов отладки. Существует до тех пор, пока предмет отладки не будет отключен или не завершит свою работу.

Подробнее об отладчике см. здесь.

Консоль кластера

Представляет собой соединение консоли кластера серверов (mmc, см. здесь) с рабочим процессом. Это соединение предназначено для администрирования информационных баз кластера серверов.

Соединение консоли кластера создается в момент обращения к данным рабочего процесса (например, при получении параметров информационной базы, при получении подробного списка соединений информационной базы и пр.).

Сервер администрирования

Представляет собой соединение сервера удаленного администрирования кластера серверов с рабочим процессом. Это соединение предназначено для администрирования информационных баз кластера серверов.

Соединение удаленного администрирования создается в момент обращения к данным рабочего процесса (например, при получении параметров информационной базы, при получении подробного списка соединений информационной базы и пр.).

COM-администратор

Представляет собой соединение с рабочим процессом сервера с использованием технологии COM. Это соединение предназначено для администрирования информационных баз кластера серверов.

Соединение COM-администратора создается при подключении к выбранному рабочему процессу с использованием технологии COM, например:

// Создать COMСоединитель 1С:Предприятия
COMСоединитель = Новый COMОбъект("V83.COMConnector");
// Установить соединение с рабочим процессом 1562
// в кластере 1541 центрального сервера TestSrv
СоединениеСРабочимПроцессом = COMСоединитель.ConnectWorkingProcess("tcp://TestSrv:1562");

Системное фоновое задание

Представляет собой соединение рабочего процесса кластера с информационной базой. Это соединение предназначено для выполнения фонового обновления конфигурации базы данных.

Соединение фонового задания существует до тех пор, пока выполняется фоновая реструктуризация.

Подробнее о фоновом обновлении конфигурации базы данных см. здесь.

Возможны следующие виды сеансов:

● Толстый клиент,

● Тонкий клиент,

● Веб-клиент,

● Конфигуратор,

● COM-соединение,

● WS-соединение,

● Фоновое задание,

● Консоль кластера,

● Сервер администрирования,

● COM-администратор.

Описание сеансов в общем соответствует описанию соответствующего соединения. Описание сеанса веб-клиента приведено ниже.

Веб-клиент

Является представлением в кластере серверов экземпляра веб-клиента. Этот сеанс предназначен для модификации данных информационной базы и выполнения другой функциональности, предоставляемой конфигурацией информационной базы. Обращение веб-клиента к серверу выполняется через соединение Модуль расширения веб-сервера.

Сеанс Веб-клиент создается в результате интерактивного запуска веб-клиента и существует до тех пор, пока не будет завершен сеанс интерактивной работы с информационной базой (закрыто последнее окно веб-браузера).

При эксплуатации клиент-серверных систем возникает задача управления возможностью создания сеансов с информационными базами:

● Ограничить количество одновременно работающих пользователей с одной информационной базой.

● Обеспечить некоторый гарантированный запас лицензий при работе с информационной базой, например, при наличии 100 лицензий обеспечить гарантированную возможность доступа к информационной базе двух пользователей с фиксированными именами.

● Другие аналогичные задачи.

Для реализации этих задач предоставляется механизм внешнего управления сеансами. Для работы механизма необходимо наличие специализированного Web-сервиса, который занимается разрешением или запрещением создания сеанса.

Предполагается следующая схема работы механизма:

● При попытке начать сеанс, кластер серверов информирует Web-сервис о необходимости создания сеанса и передает в Web-сервис набор параметров, позволяющих определить все характеристики создаваемого сеанса (имя информационной базы, имя пользователя, кластер серверов и т. д.).

● Web-сервис принимает решение о разрешении или запрещении создания сеанса и возвращает управление кластеру серверов. При необходимости, Web-сервис должен вести учет созданных сеансов в необходимых разрезах.

● При завершении сеанса, кластер серверов также информирует Web-сервис о том, что сеанс завершается.

● Если сеанс переводится в состояние Спящий или выводится из этого состояния, то кластер серверов также информирует Web-сервис о каждом из этих событий. Данная возможность доступна только для версии 2 сервиса внешнего управления сеансами.

Таким образом, система внешнего управления сеансами точно знает, какое количество сеансов сейчас создано в «подшефных» информационных базах и может принимать необходимые решения.

Описание Web-сервиса, который используется в механизме внешнего управления сеансами, и пример реализации см. здесь.

Отказоустойчивый кластер обеспечивает бесперебойную работу пользователей в следующих случаях:

● перезапуск рабочих процессов и менеджеров кластера (как плановый, так и аварийный);

● выход из строя сервера, входящего в состав кластера.

Механизмы, которые обеспечивают бесперебойную работу, описаны далее в этом разделе.

В процессе работы системы сеанс сохраняется при различных сбоях, и возможно восстановление работы после переустановки соединения. Однако существуют ситуации, при которых сеанс завершается системой и предлагается выполнить перезапуск клиентского приложения:

● в процессе вызова сервера, после фиксации первой за этот вызов транзакции, аварийно завершился рабочий процесс;

● при возврате управления клиенту произошла ошибка передачи данных.

Если в процессе вызова сервера произошла ошибка передачи данных, то это может означать, что:

● произошел обрыв канала связи,

● произошло аварийное завершение рабочего процесса сервера.

Если клиентское приложение вызвало сервер вне транзакции и ошибка передачи данных получена клиентом до фиксации первой за вызов сервера транзакции, то клиент автоматически выполняет процедуру установки соединения с сервером и повторяет тот же самый вызов. После этого его работа продолжается.

Если ошибка передачи данных получена клиентом после фиксации первой за вызов сервера транзакции, то сеанс этого клиента завершается и для продолжения работы требуется перезапуск клиентского приложения.

Если клиентское приложение вызвало сервер в транзакции (в обычном режиме работы, а не в режиме управляемого приложения), то ошибка передачи данных считается восстановимой ошибкой и приводит к аварийному завершению интерактивного действия, но не к аварийному завершению клиентского приложения.

Важно, что целостность данных приложения в этом случае не гарантируется платформой, если интерактивное действие состоит более чем из одной транзакции или меняет состояние данных приложения, кроме данных, имеющих логику кеширования.

Уровень отказоустойчивости определяет максимальное количество рабочих серверов, входящих в состав кластера, одновременный выход из строя которых не приведет к аварийному завершению сеансов подключенных пользователей. Надо понимать, что «выход из строя» подразумевает ситуации, подобные следующим: отключение питания компьютера, разрыв сетевого кабеля, проблемы с операционной системой, не позволяющие запустить процесс и т. д.

Таким образом, если в кластер серверов входит только один рабочий сервер, то максимальный уровень отказоустойчивости будет 0,т. к. выход из строя единственного рабочего сервера приведет к аварийному завершению всех подключенных пользователей. Если в кластер входит 4 рабочих сервера, то уровень отказоустойчивости может изменяться от 0 до 3. При этом 0 означает, что фатальным считается выход из строя любого рабочего сервера, а значение 3 означает, что кластер сохранит работоспособность даже в том случае, если выдут из строя 3 из 4 рабочих серверов.

Следует понимать, что увеличение уровня отказоустойчивости выполняется ценой некоторого падения производительности кластера, т. к. кластер будет тратить некоторые ресурсы на синхронизацию данных между рабочими серверами.

Уровень отказоустойчивости связан с количеством центральных серверов в кластере. Количество центральных серверов определяет возможность создания новых соединений. Если, например, в кластер входит два центральных сервера при общем количестве 3 рабочих сервера, то пользователи смогу подключаться к информационным базам в случае аварийного завершения одного центрального сервера. При этом остается два работающих рабочих сервера: один центральный и один рабочий. Если в кластере будет только один центральный сервер, то аварийное завершение этого сервера приведет к тому, что кластер станет недоступен пользователям, несмотря на то, что в нем сохранили работоспособность еще 2 рабочих сервера.

Если в кластере присутствует 3 рабочих сервера (из них один центральный) и установлен уровень отказоустойчивости равный 1, то могут наблюдаться различные ситуации. Рассмотрим их.

Выход из строя одного рабочего сервера

Аварийно завершается работа обычного рабочего сервера. Это соответствует уровню отказоустойчивости, кластер продолжает обслуживать пользователей. При этом подключение новых пользователей также возможно, т. к. сохраняет работоспособность центральный сервер.

Рис. 7. Аварийное завершение одного рабочего сервера

Выход из строя центрального сервера

Аварийно завершается работа центрального сервера. Это соответствует уровню отказоустойчивости, но кластер прекращает работу, т. к. завершил работу центральный сервер кластера.

Рис. 8. Аварийное завершение центрального сервера

Выход из строя двух рабочих серверов

Аварийно завершают работу два рабочих сервера, при этом центральный сервер сохраняет работоспособность. При этом превышен уровень отказоустойчивости, как следствие, будут завершены сеансы пользователей, которые обслуживались завершившимися рабочими серверами. Пользователи, которых обслуживает центральный сервер – сохранят работоспособность. При этом будет возможно подключение новых пользователей.

Рис. 9. Аварийное завершение двух рабочих серверов

Таким образом, можно вывести следующую формулу, связывающую количество центральных серверов в кластере и уровень отказоустойчивости: Количество центральных серверов = Уровень отказоустойчивости+1. При этом надо понимать, что буквальное следование этой формуле приведет к некоторому снижению производительности кластера, т. к. на синхронизацию реестра кластера будет тратиться некоторая часть мощности системы. При определении количества центральных серверов и уровня отказоустойчивости следует соблюдать баланс между отказоустойчивостью и приемлемым уровнем производительности кластера серверов, учитывая при этом характеристики оборудования компьютеров, входящих в состав кластера.

Системы балансировки нагрузки и обеспечения отказоустойчивости кластера для своей работы используют TCP-соединения (сетевые соединения) между компонентами кластера. Если доступность компонентов кластера определяется неверно, то и механизмы, опирающиеся на доступность компонентов, будут работать неадекватно или некорректно. Для корректного определения доступности компонентов кластера существует система отслеживания разрыва соединений между компонентами кластера.

Данная система отслеживает сетевые соединения между процессами кластера серверов (как на одном компьютере, так и на разных компьютерах), а также между кластером серверов и расширением веб-сервера, для достижения следующих целей:

● Оперативного обнаружения разрыва соединения между компонентами.

● Снижения накладных расходов на отслеживание целостности соединений между компонентами кластера.

Для целей проверки используется понятие направление проверки. Направление проверки – это группа соединений между компонентами кластера серверов, объединенных по следующим правилам:

● Исходящие соединения – по целевому адресу (имя компьютера и порт, однозначно идентифицирующие определенный компонент кластера серверов).

● Входящие соединения от расширения веб-сервера – по уникальному идентификатору, однозначно определяющему публикацию информационной базы на веб сервере;

● Остальные входящие соединения – по уникальному идентификатору, однозначно определяющему процесс источника.

Для каждого направления происходит периодическая отправка небольшого пакета данных и ожиданием ответа на него. Проверка осуществляется как на стороне источника соединений, так и на целевой стороне. Параметры проверки передаются со стороны источника соединений.

Пакеты отправляются и ожидаются по протоколам UDP и TCP. Изначально пакеты отправляются по протоколу UDP и, если в ответ не пришло ни одного ответа за все время жизни направления, то, при наступлении таймаута, устанавливается TCP-соединение и попытка проверки выполняется через это новое соединение. При этом направление продолжает считаться доступным. Режим проверки по протоколу TCP менее точен и может приводить к ложным срабатываниям при установке небольших таймаутов. При настройке кластера серверов и публикации информационных баз на веб-сервере, рекомендуется обеспечить взаимную доступность между всеми компьютерами кластера, а также между компьютерами кластера и компьютерами веб-серверов, как по протоколу TCP, так и по протоколу UDP (с теми же номерами портов). Работой системы отслеживания можно управлять с помощью двух параметров:

1. Период проверки – интервал времени, который проходит между отправкой тестового пакета.

2. Таймаут проверки – период времени, в течение которого отправитель сообщения должен получить хотя-бы один ответный пакет по выбранному направлению. Интервал времени измеряется от предыдущего получения ответного пакета (или начал работы системы).

Если за период таймаута проверки не пришло ни одного пакета от противоположной стороны, направление проверки считается недоступным, кроме случая, когда происходит переключение с протокола UDP на протокол TCP. После того, как направление проверки признано недоступным, все соединения этого направления отмечаются как непригодные для использования и будут разорваны при первом следующем обращении к ним. Одновременно с отметкой, все доступные компоненты кластера серверов оповещаются о разрыве соединений определенного направления для того, чтобы кластер мог оперативно отреагировать на грядущий разрыв соединений (в том числе для удаления блокировок, соответствующих недоступному процессу).

Администратор кластера серверов имеет возможность отслеживать качество соединения между компонентами кластера. Для этого каждые 10 секунд в технологический журнал записывается статистика проверки соединений за прошедшие 10 секунд. В частности, выводится информация о среднем времени ответа и о максимальном времени ответа. Эта информация позволяет выставить оптимальные значения таймауты проверки, которые не будут приводить к ложным срабатываниям системы проверки, но, в тоже время, обеспечат надежное функционирование самой системы. В технологическом журнале информация фиксируется в событии CONN. Более подробное описание выводимой информации см. здесь.

Если какой-либо из параметров настройки системы отслеживания разрыва соединений установлен в 0, то система отслеживания разрывов соединений начинает работать по другому алгоритму. В этом случае проверка выполняется только той стороной, которая инициировала установку сетевого соединения, при этом отсылка тестовых пакетов выполняется каждые 5 секунд. Процесс-приемник тестовых пакетов определяет разрыв соединения в том случае, если он не получил ни одного пакета в течение 200 секунд. Процесс-источник узнает о разрыве соединения только после наступления таймаута TCP-соединения, время которого определяется настройками операционной системы. При такой настройке системы отслеживания разрыва соединений период отправки сообщений и таймаут не настраивается, в технологический журнал информация о статистике соединений не выводится. Такой вариант настроек (период проверки или таймаут проверки установлены в значение 0) системы отслеживания разрыва соединений не рекомендуется к применению.

Параметры командной строки для настройки системы отслеживания разрыва соединений при запуске кластера серверов см. здесь.

Настройки системы отслеживания разрыва соединений при публикации информационной базы на веб-сервере см. здесь.

Масштабируемость кластера серверов обеспечивается несколькими способами:

● Наращиванием вычислительных мощностей компьютера, на котором развернут единственный рабочий сервер кластера.

● Возможностью включения в состав кластера серверов одного или нескольких новых рабочих серверов.

Все необходимые действия по обеспечению масштабируемости кластер серверов выполняет автоматически. Администратор кластер может влиять на действия кластера серверов с помощью изменения свойств рабочего сервера.

В список рабочих серверов кластера можно добавлять новые сервера и менять свойства существующих (см. здесь). Измененные значения свойств действуют только на новые соединения и сеансы. Удаление рабочего сервера следует проводить особым образом, чтобы не допустить аварийного отключения пользователей, которых обслуживает удаляемый сервер. Подробнее порядок удаления рабочего сервера см. здесь. Невозможно удаление последнего рабочего сервера в кластере с установленным признаком Центральный сервер. При создании кластера по умолчанию, рабочий сервер того компьютера, на котором создается кластер серверов, автоматически включается в список рабочих серверов и для этого рабочего сервера устанавливается флажок Центральный сервер.

Во время работы кластер серверов автоматически распределяет нагрузку между рабочими серверами таким образом, чтобы обеспечить минимальное время обслуживания клиентских приложений. Сервисы кластера (см. здесь) равномерно распределяются по рабочим серверам по типам сервисов, информационным базам и сеансам.

Во время установки соединения с информационной базой, кластер серверов выбирает рабочие сервера с максимальной доступной производительностью (на момент выбора рабочего сервера). Существующие соединения могут быть перемещены на другой рабочий сервер. Более подробное описание этого механизма см. здесь.

Описание других свойств, управляющих работой рабочего сервера, см. здесь.

Каждый рабочий процесс имеет свойство Доступная производительность. Оно определяет, насколько быстро данный рабочий процесс способен выполнить эталонный вызов сервера по сравнению с другими рабочими процессами. Эталонный вызов включает в себя следующие операции:

● Операция с памятью: выделение массива, заполнение массива, освобождение массива.

● Операция с файлами: создание, запись, удаление.

● Выполняется определение степени загрузки процессоров компьютера, на котором работает рабочий процесс и количество потоков, ожидающих исполнения. Это значение корректирует время выполнения эталонного вызова в сторону увеличения. Если пользователь, от имени которого работает сервер, не входит в группу Пользователи журналов производительности (Performance Log Users), то определение степени загрузки процессора не выполняется.

Значение свойства Доступная производительность вычисляется делением числа 10 000 на среднее (за 5 минут) время выполнения эталонного вызова текущим рабочим процессом. Эталонный вызов выполняется каждые 2 секунды в том случае, если в кластере присутствует несколько рабочих серверов. Если кластер серверов состоит из одного рабочего сервера – все рабочие процессы считаются равноправными.

Клиенты распределяются между рабочими процессами так, чтобы сделать доступную производительность всех рабочих процессов примерно одинаковой. Существенным считается отличие доступной производительности более чем на 25%.

При изменении соотношения между доступной производительностью рабочих процессов клиенты динамически в течение не более 10 минут перераспределяются между рабочими процессами.

При выключении рабочего процесса его клиенты динамически перераспределяются между оставшимися включенными рабочими процессами.

Примечание. Доступно только для лицензии КОРП. Подробнее о видах лицензий см. здесь.

При установке нового соединения с сервером «1С:Предприятия», системе можно указать, каким образом выбирать рабочий процесс (свойство кластера серверов Режим распределения нагрузки):

● Приоритет по производительности,

● Приоритет по доступной памяти.

Режим выбора с приоритетом по производительности

При установке нового соединения с сервером «1С:Предприятия» вначале выбирается рабочий сервер с максимальной производительностью. Если таких серверов несколько – рабочий сервер выбирается произвольным образом из этого списка. Затем на выбранном рабочем сервере выбирается рабочий процесс, который обслуживает максимальное количество соединений с необходимой информационной базой. Если таких рабочих процессов несколько – выбирается процесс, который обслуживает максимальное количество соединений с любыми информационными базами. Если и таких рабочих процессов несколько – рабочий процесс выбирается произвольным образом из этого списка.

Существующее соединение с сервером «1С:Предприятия» может быть переустановлено с другим рабочим процессом в одном из следующих случаев:

● текущий рабочий процесс выключен;

● есть рабочий процесс с доступной производительностью не менее чем на 25% большей, чем у данного рабочего процесса.

Переустановка соединения возможна, если выполняются все условия, перечисленные ниже:

● клиентский поток не исполняется на сервере,

● нет открытой транзакции,

● не создано ни одной временной таблицы.

Режим выбора с приоритетом по памяти

При установке нового соединения с сервером «1С:Предприятия» выбирается процесс, который уже обслуживает соединения с нужной информационной базой. Если такой рабочий процесс не обнаружен, то выбирается рабочий процесс, который запущен на сервере с наибольшим количество свободной оперативной памяти.

Если существует несколько рабочих серверов, которые обслуживают соединения с необходимой информационной базой, то будет выбран сервер с максимальной доступной производительностью. Если на рабочем сервере есть несколько рабочих процессов, обслуживающих соединения с необходимой информационной базой, то будет выбран рабочий процесс с максимальным количеством соединений с этой базой.

Существующее соединение с сервером «1С:Предприятия» может быть переустановлено с другим рабочим процессом в одном из следующих случаев:

● текущий рабочий процесс выключен;

● есть рабочий процесс с доступной производительностью, не менее чем на 25% большей, чем у данного рабочего процесса и обслуживающего ту же информационную базу, что и данный рабочий процесс.

Переустановка соединения возможна, если выполняются все условия, перечисленные ниже:

● клиентский поток не исполняется на сервере,

● нет открытой транзакции,

● не создано ни одной временной таблицы.

При выполнении обращения к серверу от имени нового сеанса система:

● Выбирает любое соединение из пула соединений, который существует у расширения веб-сервера.

● Если в пуле нет свободных соединений, то производится создание нового соединения в соответствии с параметром кластера Режим распределения нагрузки.

При выполнении обращения от имени существующего сеанса:

● В пуле соединений выполняется поиск соединения с тем же рабочим процессом, через который выполнялось взаимодействие в прошлый вызов. В случае успеха – используется найденное соединение.

● Происходит попытка выбора рабочего процесса, в соответствии с параметром кластера Режим распределения загрузки, при этом приоритет в поиске отдается рабочему процессу, через который выполнялось предыдущее обращение к серверу. Новый рабочий процесс будет выбран в том случае, если он существенно лучше (по производительности или свободной памяти), чем «старый» рабочий процесс. Если к полученному рабочему процессу есть свободные соединения – будет использовано одно из них.

● Иначе происходит создание нового соединения в соответствии с параметром кластера Режим распределения загрузки.

Примечание. Доступно только для лицензии КОРП. Подробнее о видах лицензий см. здесь. Обычная серверная лицензия позволяет использовать требования назначения функциональности в том случае, если в этих правилах не указываются дополнительные параметры (имя информационной базы, имя приложения или вид фонового задания). В частности, допускается выносить на отдельные рабочие сервера какие-либо сервисы кластера (например, сервис лицензирования).

Кластер серверов предоставляет некоторый набор функциональных возможностей (называемые объекты требований), распределением которых между рабочими серверами внутри кластера можно управлять. Например, можно указать, что все фоновые задания в кластере будут выполняться на выбранном рабочем сервере.

Для того чтобы поместить соединение или сервис кластера на какой-либо рабочий сервер, необходимо для выбранного рабочего сервера создать требование назначения функциональности. Это требование определяет возможность или невозможность конкретного сервера выполнять ту или иную работу. Рассмотрим более подробно, что собой представляет требование назначения функциональности.

Требование назначения функциональности определяет:

● Для какого объекта требования создается требование. В качестве объекта требования могут выступать некоторые сервисы кластера (см. здесь), клиентские соединения (см. здесь) и произвольный объект требования. В качестве объекта требования могут выступать следующие сервисы кластера:

● Блокировок объектов.

● Времени.

● Журналов регистрации.

● Заданий.

● Нумерации.

● Полнотекстового поиска.

● Пользовательских настроек.

● Сеансовых данных.

● Транзакционных блокировок.

● Работы с внешними источниками данных через ODBC.

● Работы с внешними источниками данных через XMLA.

● Сервис лицензирования.

● Сервис фонового обновления конфигурации базы данных.

● Сервис тестирования.

● Сервис внешнего управления сеансами.

● Определяет тип требования. Тип требования определяет, каким образом будет выполняться использование рабочего сервера:

● Не назначать – означает, что рабочий сервер, для которого создано данное требование, не будет назначен для обслуживания объекта требования, подходящего под условия, заданные в требовании.

● Назначать – означает, что рабочий сервер, для которого создано данное требование, будет являться одним из кандидатов на обслуживание данного объекта требования (если рабочих серверов будет несколько).

● Авто – означает, что рабочий сервер может быть использован для обслуживания объекта требования в том случае, если нет рабочего сервера с явным указанием необходимости использования.

Совет. Тип требования Авто имеет смысл использовать тогда, когда в списке требований рабочего сервера есть требование с более широким набором условий, и необходимо иметь требование для более узкого набора условий. Например, данный сервер не может обслуживать соединения клиентских приложений для всех информационных баз, кроме одной информационной базы, для которой такое обслуживание разрешено.

● Дополнительные параметры, необходимые кластеру серверов для принятия решения в ряде случаев:

● Имя информационной базы. Используется для уточнения требования для формирования требований для клиентских соединений и всех сервисов кластера, которые могут выступать в качестве объекта требования, кроме сервиса лицензирования.

● Дополнительные параметры. Используются для уточнения требований при размещении клиентского соединения или сервиса сеансовых данных. Дополнительный параметр проверяется на совпадение с началом соответствующего параметра объекта требования. Дополнительный параметр может принимать одно из следующих значений:

● Для указания регламентного задания: BackgroundJob.ScheduledJob.<Имя объекта конфигурации>;

● Для указания конкретного фонового задания, запущенного из встроенного языка: BackgroundJob.CommonModule.<Имя модуля>.<Имя метода>;

● Для указания всех фоновых заданий, запущенных из встроенного языка: BackgroundJob.CommonModule;

● Для указания отчета (включая внешний отчет): BackgroundJob.GenerateReport.<Полное имя объекта конфигурации>.

● Ввод по строке: BackgroundJob.InputByString.<Полное имя объекта конфигурации>;

● Поиск в списке: BackgroundJob.DynamicListSearch.<Полное имя формы>.<Имя таблицы формы связанной со списком>;

● Для указания фоновой реструктуризации: SystemBackgroundJob.DBConfigUpdate;

● Для клиентского приложения:

● 1CV8 – толстый клиент;

● 1CV8CDirect – тонкий клиент в случае прямого подключения к серверу «1С:Предприятия»;

● Designer – конфигуратор;

● COMConnection – COM-соединение;

● WebServerExtension – соединение с информационной базой через веб-сервер: веб-клиент, тонкий клиент в случае подключения через веб-сервер, Web-сервис.

Рассмотрим, как работает кластер серверов при обработке требований.

В случае необходимости выполнить размещение объекта требования, кластер выполняет следующие действия:

● На всех серверах, входящих в состав кластера, выполняется обработка заданных для этих серверов требований назначения функциональности. Обход серверов и требований выполняется в порядке следования этих объектов в консоли кластера.

● В каждом списке требований определяется первое требование, которое удовлетворяет размещаемому объекту: по собственно объекту, информационной базе и дополнительному параметру.

● Затем полученный список рабочих серверов сортируется по признаку типа требования так, что первыми оказываются рабочие сервера с явным указанием использования. Рабочие сервера, для которых подходящее требование содержит явный запрет на использование – исключаются из списка доступных рабочих серверов. При этом назначение выполняется следующим образом:

● Есть рабочие сервера с явным указанием использования: в этом случае объект требования будет обслужен одним из этих рабочих серверов.

● Нет рабочих серверов с явным указанием использования: происходит попытка использовать рабочие сервера с автоматическим указанием использования или те рабочие серверы, для которых не указано требований.

● Подробное описание правил выбора рабочего сервера для обслуживания объекта требования см. здесь.

● При размещении клиентского соединения, из списка доступных серверов будет выбран тот, в состав которого входит рабочий процесс с наивысшей доступной производительностью (см. здесь). Подробное описание правил выбора рабочего процесса в конкретном рабочем сервере см. здесь.

Клиентское приложение, инициировавшее размещение объекта требования, будет завершено аварийно в одном из следующих случаях:

● Если для объекта требования список рабочих серверов оказывается пустым – нет ни одного рабочего сервера, который может обслужить объект. При этом объект требования не будет размещен и будет вызвано исключение.

● Если невозможно выполнить размещение на выбранном рабочем сервер, например, если выбранный сервер вышел из строя, и нет альтернативных рабочих серверов.

Более подробно рассмотрим алгоритм назначения рабочего сервера для обслуживания сервиса кластера.

Для сервисов кластера (см. здесь) объектом требования может выступать:

● Сервис одного типа, если сервис не делится по информационным базам.

● Сервис одного типа для одной информационной базы, если сервис делится по информационным базам.

● Сервис сеансовых данных.

● Сервис лицензирования.

Сервисы распределяются между подходящими рабочими серверами следующим образом:

● Из перечня выбранных для назначения рабочих серверов выбираются те, которые в данный момент работоспособны. Среди оставшихся рабочих серверов выбираются те сервера, у которых свойство Приоритет содержит максимальное значение.

● Среди отобранных рабочих серверов сервисы распределяются равномерно.

● Сервисы, поддерживающие репликацию, могут назначаться на несколько рабочих серверов. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь). При этом один сервис будет являться активным, а с другими сервисами (резервными) будет поддерживаться репликация служебных данных сервиса. Репликация выполняется асинхронно. Синхронизация выполняется каждую секунду.

● Сервисы, которые не поддерживают перенос данных, назначаются на все рабочие серверы кластера с установленным флажком Центральный сервер (см. здесь).

● Для каждого сеанса, который обслуживает кластер серверов, создается свой экземпляр сервиса сеансовых данных. При отборе рабочих серверов, которые могут обслужить данный экземпляр сервиса, учитываются дополнительные параметры требования. Из списка доступных выбираются сервера с минимальным количеством обслуживаемых сервисов кластера. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь).

● В случае необходимости использования сервиса лицензирования следует явно выбрать рабочий сервер, к которому будет выполняться привязка программной лицензии и явно описать в требованиях размещение сервиса на выбранном рабочем сервере.

● Остальные сервисы назначаются в единственном экземпляре.

Переназначение сервисов кластера между рабочими серверами может выполняться в следующих случаях:

● При добавлении рабочего сервера выполняется частичное переназначение сервисов. Данное переназначение выполняется автоматически.

● При удалении рабочего сервера из состава кластера или недоступности рабочего сервера выполняется переназначение только тех объектов требований, которые обслуживал удаляемый рабочий сервер. Данное переназначение выполняется автоматически.

● При удалении или добавлении информационной базы в кластер выполняется частичное переназначение. Данное переназначение выполняется автоматически.

● Переназначение происходит также в том случае, если администратор кластера выполнит операцию полного или частичного применения требований из консоли кластера (см. здесь).

При запуске кластера на каждом рабочем сервере запускается по одному рабочему процессу и начинается процесс вычисления доступной производительности для каждого рабочего сервера (см. здесь).

Установка соединения клиентского приложения с кластером серверов «1С:Предприятия» выполняется по следующим правилам:

● В соответствии с требованиями назначения и ограничениями по использованию оперативной памяти отбирается необходимый рабочий сервер.

Ограничения по использованию оперативной памяти учитываются в том случае, если запрос на установку соединения выполняется к информационной базе, к которой нет установленных соединений на выбранном рабочем сервере. В случае превышения лимита использования оперативной памяти рабочий сервер исключается из списка, если существует другой рабочий сервер, который не превысил лимит. Также исключаются рабочие сервера, которые не могут обработать требуемое соединение исходя из требований назначения.

● Для выбранного сервера определяется список рабочих процессов, которые доступны и могут обслужить запрашиваемое соединение. Рабочий процесс относится к списку доступных рабочих процессов в следующих случаях:

● Для рабочего процесса не достигнуто максимальное количество обслуживаемых информационных баз (свойство рабочего сервера Количество ИБ на процесс).

● Для рабочего процесса не достигнуто максимальное количество обслуживаемых соединений (свойство рабочего сервера Количество соединений на процесс).

● Рабочий процесс не находится в состоянии подготовки к автоматическому перезапуску.

● Из выбранных рабочих процессов предпочтение отдается тем рабочим процессам, которые уже обслуживают соединения информационной базы, соединение с которой необходимо обслужить. Если такого рабочего процесса нет – выбирается рабочий процесс с максимальным количеством обслуживаемых соединений.

● Если не удалось выбрать ни один рабочий процесс, то на данном рабочем сервере запускается новый рабочий процесс, который и будет обслуживать запрошенное соединение.

При установке соединения от лица существующего сеанса (если не удалось повторно использовать соединение предыдущего вызова сервера) предпочтение отдается рабочему процессу, который обслуживал предыдущее соединение этого сеанса. При этом возможен выбор другого рабочего процесса, если доступная производительность другого рабочего процесса выше доступной производительности текущего рабочего процесса не менее чем на 25%.

Если на одном рабочем сервере в течение 20 минут существуют 2 рабочих процесса, для которых суммарное количество обслуживаемых соединений и различных информационных баз меньше, чем значения, указанные в свойствах рабочего сервера (свойства Количество соединений на процесс и Количество ИБ на процесс), то процесс, который обслуживает меньшее количество соединений, будет помечен как устаревший и будет остановлен после разрыва последнего соединения. Существующим соединениям с «устаревшим» рабочим процессом будет «предложено покинуть» рабочий сервер при ближайшем серверном вызове через данное соединение. При этом «устаревший» рабочий процесс не участвует в распределении запросов на обслуживание новых объектов требований.

При подсчете количества обслуживаемых соединений учитываются соединения, которые создаются отладчиком для проверки прав доступа на предмет отладки.

При рассмотрении примеров требований назначений функциональности будет использоваться следующий кластер серверов:

Рис. 10. Кластер для примеров требований

Кластер обладает следующими характеристиками:

● Количество рабочих серверов: 3.

● Уровень отказоустойчивости: 1.

● Количество центральных серверов: 2 (SRV1, SRV2).

● Операционные системы на рабочих серверах:

● Сервер SRV1, ОС Windows.

● Сервер SRV2, ОС Linux.

● Сервер SRV3, ОС Windows.

Кластер обслуживает следующие информационные базы:

● DemoDB,

● WorkDB.

Внимание! Приведенные ниже примеры не являются законченными решениями какой-либо проблемы, а служат только для демонстрации принципов работы механизма размещения объектов требований по рабочим серверам в кластере.

Если необходимо разместить все фоновые задания на рабочем сервере SRV1, то для этого необходимо для рабочего сервера SRV1 задать следующее требование назначения функциональности:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.CommonModule.

Необходимо многопользовательскую клиентскую лицензию активировать для компьютера, на котором функционирует рабочий сервер SRV2, разместить на этот компьютер сервис лицензирования и не размещать на этот компьютер больше никаких сервисов. Тогда для рабочего сервера SRV2 следует указать следующие требования:

● Требование 1:

● Объект требования: Сервис лицензирования.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

● Требование 2:

● Объект требования: Любой объект требования.

● Тип требования: Не назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

Требование 1 обеспечит функционирование сервиса лицензирования на сервере SRV2, а Требование 2 обеспечит функционирование на сервере SRV2 только сервиса лицензирования (на сервере SRV2 не будут функционировать другие сервисы кластера).

При активации программной лицензии с помощью сервера «1С:Предприятия» следует указывать имя SRV2, в противном случае активированная лицензия не сможет быть использована кластером серверов, т. к. программная лицензия будет активирована для другого компьютера.

Необходимо разрешить работу сервиса работы с внешними источниками данных на рабочих серверах SRV1 и SRV3, и запретить – на рабочем сервере SRV2. Для этого следует для рабочего сервера SRV2 указать следующее требование:

● Объект требования: Сервис работы с внешними источниками данных.

● Тип требования: Не назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: не указывается.

Необходимо настроить кластер серверов таким образом, чтобы каждая информационная база обслуживалась одним рабочим процессом. Для этого необходимо для каждого рабочего сервера установить свойство Количество ИБ на процесс в значение 1.

В результате на каждом сервере будет создано по два рабочих процесса (всего – 6, по 2 рабочих процесса на каждый из 3 рабочих серверов). При этом обслуживанием одной информационной базы будет заниматься 3 рабочих процесса на 3 рабочих серверах.

Необходимо настроить кластер серверов таким образом, чтобы информационную базу DemoDB обслуживал только рабочий сервер SRV3, а информационную базу WorkDB обслуживали оба рабочих сервера: SRV1 и SRV2. Для этого необходимо настроить следующие правила:

● Для рабочего сервера SRV3:

● Объект требования: Любой объект требования.

● Тип требования: Назначать.

● Имя ИБ: DemoDB.

● Значение дополнительного параметра: не указывается.

● Для рабочих серверов SRV1 и SRV2:

● Объект требования: Любой объект требования.

● Тип требования: Назначать.

● Имя ИБ: WorkDB.

● Значение дополнительного параметра: не указывается.

Указанные правила «разнесут» по рабочим серверам все механизмы кластера серверов: соединения, фоновые задания, сервисы сеансовых данных и т. д.

Необходимо настроить кластер серверов таким образом, чтобы на рабочем сервере SRV1 выполнялись только отчеты, на рабочем сервере SRV2 выполнялись только регламентные задания ОбновлениеИндексаППД и ОбновлениеАгрегатовПродаж, а остальные фоновые задания должны выполняться на рабочем сервере SRV3. Для этого необходимо настроить следующие правила:

● Для рабочего сервера SRV1:

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.Report.

● Для рабочего сервера SRV2:

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.CommonModule.РаботаСПолнотекстовымПоиском.ОбновлениеИндексаПолнотекстовогоПоиска.

● Требование:

● Объект требования: Клиентское соединение с ИБ.

● Тип требования: Назначать.

● Имя ИБ: не указывается.

● Значение дополнительного параметра: BackgroundJob.CommonModule.РегламентныеЗаданияАгрегатов.ОбновлениеАгрегатовПродаж.

Примечание. Доступно только для лицензии КОРП. Подробнее о видах лицензий см. здесь.

Работающее прикладное решение может использовать для своих нужд различные внешние ресурсы: каталоги файловой системы, COM-объекты (на Windows-системах), внешние компоненты, приложения ОС и т. д. Однако, по соображениям безопасности, для различных прикладных решений могут быть доступны не все возможные внешние ресурсы, а только ограниченное их подмножество. Может потребоваться создать собственный каталог временных файлов для каждой области разделенной информационной базы или задать перечень ресурсов сети Интернет, к которым может иметь доступ прикладное решение.

Чтобы установить такие ограничения, для кластера серверов можно настроить профили безопасности. Профиль безопасности – это набор явно заданных разрешений использования теми или иными внешними ресурсами (с указанием перечня таких ресурсов), которые можно назначать информационным базам, зарегистрированным в кластере. Профили безопасности создаются администратором кластера и позволяют настраивать следующие разрешения:

● Возможность использования данного профиля в качестве профиля безопасности безопасного режима – если это разрешение установлено (свойство профиля Может использоваться как профиль безопасности безопасного режима), то имя данного профиля безопасности можно указывать во встроенном языке при включении безопасного режима и подключении внешних отчетов и обработок;

● Доступные ресурсы файловой системы сервера (см. здесь);

● Доступные COM-объекты (только для серверов, работающих под управлением ОС Windows) (см. здесь);

● Доступные внешние компоненты (см. здесь);

● Доступные внешние модули (внешние отчеты, обработки, расширения конфигурации), а также возможность использования оператора Выполнить() и функции Вычислить() (см. здесь);

● Доступные приложения операционной системы (см. здесь);

● Доступные ресурсы сети Интернет (см. здесь);

● Возможность доступа к привилегированному режиму – если данное разрешение установлено (свойство профиля Разрешен полный доступ: к привилегированному режиму), то при использовании данного профиля в качестве профиля безопасного режима, разрешено включать привилегированный режим (см. здесь);

● Возможность доступа к функциям криптографии (см. здесь).

Для того чтобы информационная база использовала для работы созданный профиль безопасности, следует указать его имя в свойствах информационной базы (с помощью средств администрирования кластера серверов). Также в свойствах информационной базы можно указать имя профиля, который будет использоваться при установке в прикладном решении безопасного режима.

Некоторые разрешения позволяют задавать список разрешенных ресурсов. Это разрешения:

● Доступные ресурсы файловой системы сервера;

● Доступные COM-объекты (только для серверов, работающих под управлением ОС Windows);

● Доступные внешние компоненты;

● Доступные внешние модули;

● Доступные приложения операционной системы;

● Доступные ресурсы сети Интернет.

В этом случае работа осуществляется следующим образом:

● Если в профиле безопасности флажок сброшен (например, доступ к ресурсам сети Интернет), то из информационной базы, для которой указан данный профиль безопасности, невозможно использовать ни одного ресурса сети Интернет.

● Если в профиле безопасности этот флажок установлен, то прикладное решение обладает полным доступом к ресурсам сети Интернет.

● Если требуется предоставить ограниченный доступ (по списку), то следует отключить флажок и задать список ресурсов, доступ к которым разрешен.

Далее подробнее рассмотрим работу с конкретными разрешениями.

Для доступа к файловым ресурсам сервера применяются виртуальные каталоги. Это означает, что в рамках профиля безопасности существует некоторая виртуальная файловая система, в которой создаются каталоги. Каждый виртуальный каталог имеет отражение на реальную файловую систему по определенным правилам. В тот момент, когда прикладному решению необходимо выполнить файловую операцию, в параметре соответствующей функции указывается путь к файлу, расположенному в виртуальной файловой системе. «1С:Предприятие» транслирует виртуальный каталог в реальный и формирует реальный путь к файлу, с которым и выполняется реальная работа. Прикладное решение не может получить информацию о том, в какой физический путь будет отражен виртуальный каталог.

Если в профиле безопасности указаны несколько виртуальных каталогов, то прикладное решение может осуществлять доступ только к этим ресурсам. Попытка доступа к любому другому каталогу (как реальному, так и виртуальному) – невозможна.

Виртуальные каталоги используются при обращении к методам встроенного языка:

● Глобальный контекст:

● КаталогПрограммы(),

● КаталогВременныхФайлов(),

● ЗначениеВФайл(),

● ЗначениеИзФайла(),

● КопироватьФайл(),

● ПереместитьФайл(),

● УдалитьФайлы(),

● НайтиФайлы(),

● СоздатьКаталог(),

● РазделитьФайл(),

● ОбъединитьФайлы(),

● ПолучитьИмяВременногоФайла().

● Объект Картинка:

● конструктор на основании имени файла,

● Записать().

● Объект ДвоичныеДанные:

● конструктор на основании имени файла,

● Записать().

● Объект ИзвлечениеТекста:

● конструктор на основании имени файла,

● изменение свойства ИмяФайла,

● Записать().

● Объект ТекстовыйДокумент:

● Записать(),

● Прочитать().

● Объект ТабличныйДокумент:

● Записать(),

● Прочитать().

● Объект ФорматированныйДокумент:

● Записать().

● Объект ГрафическаяСхема:

● Записать(),

● Прочитать().

● Объект ГеографическаяСхема:

● Записать(),

● Прочитать().

● Объект Файл:

● конструктор на основании имени файла.

● Объект xBase:

● конструктор на основании имени файла.

● ОткрытьФайл(),

● СоздатьИндексныйФайл(),

● СоздатьФайл().

● Объект ЧтениеXML:

● ОткрытьФайл().

● Объект ЗаписьXML:

● ОткрытьФайл().

● Объект КаноническаяЗаписьXML:

● ОткрытьФайл().

● Объект ПреобразованиеXSL:

● ЗагрузитьИзФайла(),

● ПреобразоватьИзФайла().

● Объект ЧтениеFastInfoset:

● ОткрытьФайл().

● Объект ЗаписьFastInfoset:

● ОткрытьФайл().

● Объект ЗаписьZipФайла:

● конструктор на основании имени файла,

● Добавить(),

● Открыть().

● Объект ЧтениеZipФайла:

● конструктор на основании имени файла,

● Извлечь(),

● ИзвлечьВсе(),

● Открыть().

● Объект СертификатКлиентаФайл:

● конструктор по умолчанию.

● Объект СертификатыУдостоверяющихЦентровФайл:

● конструктор по умолчанию.

● Объект ЗаписьHTML:

● ОткрытьФайл().

● Объект ЧтениеHTML:

● ОткрытьФайл().

● Объект ЧтениеТекста:

● конструктор на основании имени файла,

● Открыть().

● Объект ЗаписьТекста:

● конструктор на основании имени файла,

● Открыть().

● Объект СертификатКриптографии:

● конструктор на основании имени файла.

● Объект МенеджерКриптографии:

● Подписать(),

● ПроверитьПодпись(),

● Зашифровать(),

● Расшифровать(),

● ПолучитьСертификатыИзПодписи().

● Объект ХешированиеДанных:

● ДобавитьФайл().

Виртуальный каталог описывается несколькими параметрами:

● Логический URL – адрес, который будет использоваться прикладным решением. Этот параметр должен выглядеть как начало реального пути в соответствующей файловой системе (для ОС Windows или Linux). Прикладное решение может использовать только такие пути, которые начинаются со значения, указанного в этом свойстве. Является уникальным в рамках одного профиля.

Существуют два предопределенных логических URL, которые используются методами системы:

● /bin – каталог загрузочных модулей текущей версии «1С:Предприятия». Этот виртуальный каталог используется методом КаталогПрограммы().

● /temp – каталог временных файлов. Этот виртуальный каталог используется методом КаталогВременныхФайлов().

● Физический URL – адрес, указывающий физическое размещение логического URL в файловой системе сервера. Может включать специальные подстановочные символы. В процессе выполнения файловой операции «1С:Предприятие» преобразует логический URL в реальный адрес файловой системы заменой всех подстановочных символов. При этом каждая последовательность символов, не допустимых в URL, заменяется на символ "_".

Внимание! В общем случае прикладное решение само обязано следить за существованием физического отображения виртуального каталога.

В адресе можно использовать следующие подстановочные символы:

● %r – ссылочное имя информационной базы;

● %i – идентификатор информационной базы;

● %z – строковое представление текущих значений разделителей текущего сеанса в формате, принятом для параметра командной строки /Z.

● %s – номер сеанса;

● %c – номер соединения;

● %p – идентификатор безопасного режима исполнения прикладного кода;

● %e – каталог загрузочных модулей «1С:Предприятия»;

● %t – текущий каталог временных файлов операционной системы;

● %u – каталог данных приложений текущего пользователя;

● %a – каталог данных приложений всех пользователей;

● %n – имя текущего пользователя информационной базы;

● %% – символ %.

● Разрешено чтение данных – флажок определяет, допустимо или нет чтение файлов из данного виртуального каталога.

● Разрешена запись данных – флажок определяет, допустима или нет запись файлов в данном виртуальном каталоге.

При указании физически URL возможно указание как на собственные каталоги компьютера, на котором установлено «1С:Предприятие» и на сетевые ресурсы. При этом надо учитывать особенности организации файловых систем и работы с сетевыми ресурсами той операционной системы, на которой функционирует сервер.

При завершении сеанса удаляются физические каталоги, в определении которых участвовал символ подстановки %s. При завершении соединения удаляются физические каталоги, в определении которых участвовал символ подстановки %с. Вход в безопасный режим исполнения кода на встроенном языке обладает собственным уникальным идентификатором. При выходе из безопасного режима удаляются физические каталоги, в определении которых участвовал символ подстановки %p.

Профиль безопасности кластера может содержать список классов COM-объектов, которые можно использовать в прикладном решении.

Внимание! Данная возможность применима только для серверов, работающих под управлением ОС Windows.

Если информационная база ссылается на профиль безопасности, в котором ограничено использование COM-объектов, то возможно использование только тех классов COM-объектов, которые перечислены в списке разрешенных COM-классов этого профиля. Используемый конфигурацией COM-объект соответствует элементу списка разрешенных COM-объектов профиля безопасности, если совпадает значение свойства Компьютер COM-объекта и совпадают отличные от пустых значения свойства Файл (моникер) и Идентификатор COM-класса. При попытке создания экземпляра любого COM-объекта, отсутствующего в списке, будет выдано исключение.

Разрешенный класс COM-объекта описывается следующими параметрами:

● Имя – уникальное имя класса COM-объекта. Является уникальным в рамках одного профиля.

● Файл (моникер) – имя файла-моникера. Используется при вызове метода ПолучитьCOMОбъект() с неуказанным значением параметра ИмяКлассаCOM. Подробнее про файл-моникер можно прочитать по адресу: http://msdn.Microsoft.com/ru-RU/library/windows/desktop/ms688670(v=vs.85).aspx (на английском языке).

● Идентификатор COM-класса – строка, представляющая собой идентификатор класса COM-объекта, в формате реестра ОС Windows, без обрамляющих фигурных скобок. Данное значение используется в конструкторе нового COM-объекта и методе ПолучитьCOMОбъект().

● Компьютер COM-объекта – компьютер, на котором может быть создан COM-объект. Используется конструктором нового COM-объекта. Для указания текущего компьютера следует использовать строку localhost, пустая строка означает, что COM-объект может создаваться на любом компьютере.

Профиль безопасности кластера может содержать список внешних компонент, которые можно использовать в прикладном решении. Если информационная база ссылается на профиль безопасности, в котором ограничено использование внешних компонент, то возможно использование только тех внешних компонент, которые перечислены в списке разрешенных внешних компонент этого профиля. При попытке выполнения метода ПодключитьВнешнююКомпоненту() для компоненты, отсутствующей в списке, будет выдано исключение. Пустой список значит, что данный профиль не позволяет использовать никакие внешние компоненты.

Разрешенная внешняя компонента описывается следующими параметрами:

● Имя – уникальное имя внешней компоненты. Является уникальным в рамках одного профиля.

● Контрольная сумма – контрольная сумма SHA1 разрешенной внешней компоненты, преобразованная к формату base64.

Для построения контрольной суммы можно использовать объект ХешированиеДанных и метод глобального контекста Base64Строка().

Если оформляется разрешение для внешней компоненты, разработанной по технологии Native API, то для каждого, поддерживаемого компонентой, типа платформы необходимо задавать отдельное разрешение. Таким образом, внешняя компонента, поддерживающая все платформы, будет иметь 4 разрешения: для 32– и 64-разрядной ОС Windows и для 32– и 64-разрядной ОС Linux.

Профиль безопасности кластера может содержать список внешних модулей, которые можно использовать из кода прикладного решения без включения безопасного режима. Под внешними модулями понимаются: внешние отчеты и обработки, а также расширения конфигурации. Если информационная база ссылается на профиль безопасности, в котором ограничено использование внешних модулей, то возможно использование без включения безопасного режима только тех внешних модулей, которые перечислены в этом списке. При попытке использования внешнего модуля, не содержащегося в этом списке, без включения безопасного режима, будет выдано исключение. Пустой список значит, что данный профиль не позволяет использовать никакие внешние модули без включения безопасного режима. Также с помощью данного элемента профиля управляется возможность использования оператора Выполнить() и функции Вычислить() в безопасном режиме. Если в профиле безопасности флажок Разрешен полный доступ: к внешним модулям сброшен, то в прикладном решении можно использовать Выполнить() и Вычислить() только в безопасном режиме (явно устанавливая его перед использованием оператора или функции). Если прикладное решение использует Выполнить() и Вычислить() в технологических целях (в небезопасном режиме), то для него нельзя использовать профиль безопасности, у которого сброшен флажок Разрешен полный доступ: к внешним модулям.

Разрешенный внешний отчет или обработка описывается следующими параметрами:

● Имя – уникальное имя внешнего модуля. Является уникальным в рамках одного профиля.

● Контрольная сумма – контрольная сумма SHA1 разрешенного внешнего отчета или обработки, преобразованная к формату base64.

Для построения контрольной суммы можно использовать объект ХешированиеДанных и метод глобального контекста Base64Строка(). Для расширения конфигурации контрольную сумму можно получить или с помощью программного интерфейса или с помощью Конфигуратора (команда главное меню – Конфигурация – Расширения конфигурации – Действия – Показать контрольную сумму).

Профиль безопасности кластера может содержать список приложений, которые можно запускать из прикладного решения. Если информационная база ссылается на профиль безопасности, в котором ограничен запуск приложений, то возможно использование только тех приложений (исполняемых файлов), которые перечислены в списке разрешенных приложений этого профиля. При попытке выполнения метода ЗапуститьПриложение() с приложением или параметрами, которым не соответствует ни одной записи в списке, будет выдано исключение. Пустой список значит, что данный профиль не позволяет использовать никакие приложения.

Разрешенное приложение операционной системы описывается следующими параметрами:

● Имя – имя приложения. Уникально в пределах профиля безопасности.

● Шаблон строки запуска – шаблон строки запуска приложения. Состоит из последовательности шаблонных слов, разделенных пробелами. Шаблонное слово представляет собой произвольную последовательность символов и может содержать символы подстановки. Если шаблонное слово может содержать пробелы, то оно должно быть заключено в кавычки.

Символы подстановки:

● % – произвольная последовательность символов;

● _ – один произвольный символ;

● * – имя файла. Если шаблонное слово начинается с символа *, то параметр является маршрутом от виртуального каталога. Перед выполнением виртуальный каталог заменяется на реальный каталог.

● \ – префикс символа. Указание данного символа перед шаблонным словом делает слово не шаблонным.

Проверка соответствия запускаемого приложения списку разрешенных приложений выполняется для имени запускаемого приложения и каждого из параметров, имеющихся в команде запуска. Отсутствие соответствующего шаблонного слова значит, что шаблон не соответствует строке запуска.

Например, шаблон xcopy */temp/% */userdata/% позволяет выполнять копирование произвольного файла из виртуального каталога /temp в виртуальный каталог /userdata.

В строке запуска параметры разделяются одним или несколькими пробелами.

Строка, заключенная в кавычки ("), является одним параметром. Одним параметром считается последовательность слов, если первое и последнее слово содержит нечетное количество одиночных символов кавычки. Если есть первое слово с кавычками, но нет второго, то одним параметром считается все до конца строки. Если параметр не заключен в кавычки, то символ кавычки представляется парой символов \". Символ кавычки в составе параметра, заключенного в кавычки, может представляться одной из пар символов: \" или "".

Профиль безопасности может содержать список ресурсов интернет, к которым разрешены обращения из серверного кода прикладного решения. Если в профиле безопасности ограничено использование интернет, то использование объекта ИнтернетСоединение запрещено, а при помощи объектов ИнтернетПочта, HTTPСоединение, FTPСоединение, WSОпределения разрешено обращение только к тем ресурсам, которые перечислены в списке разрешенных ресурсов интернет этого профиля. При обращении к другим ресурсам будет порождено исключение. Пустой список значит, что запрещено обращение к любым ресурсам интернет.

Разрешенный ресурс сети Интернет описывается следующими параметрами:

● Имя – имя ресурса для его идентификации. Уникально в пределах профиля безопасности.

● Адрес – адрес ресурса без указания протокола.

● Порт – номер порта, через который выполняется взаимодействие с указанным ресурсом.

● Тип ресурса (протокол) – протокол, по которому выполняется взаимодействие с ресурсом. Могут быть указаны следующие протоколы (регистр символов не играет роли):

● imap – сервер электронной почты, работающий по протоколу IMAP.

● pop3 – сервер электронной почты, работающий по протоколу POP3.

● smtp – сервер электронной почты, работающий по протоколу SMTP.

● http – веб-сервер.

● https – защищенное соединение с веб-сервером.

● ftp – ftp-сервер.

● ftps – защищенное соединение с ftp-сервером.

При установленном разрешении Привилегированный режим разрешено включать привилегированный режим в том случае, если профиль с установленным разрешением выбран в качестве профиля безопасного режима. При этом возможность получать доступ к различным внешним ресурсам определяется параметрами установленного профиля безопасности.

Доступ к функциям криптографии на стороне сервера регулируется специальным разрешением профиля безопасности. Если соответствующий флажок установлен, то допустимо использовать любые методы объекта МенеджерКриптографии. В противном случае использование методов будет приводить к генерации исключения.

Разрешение профиля безопасности влияет на работу следующих методов объекта МенеджерКриптографии:

● Зашифровать();

● Подписать();

● ПолучитьИнформациюМодуляКриптографии();

● ПолучитьСертификатыИзПодписи();

● ПолучитьХранилищеСертификатов();

● ПроверитьПодпись();

● ПроверитьСертификат();

● Расшифровать().

При работе «1С:Предприятия» в варианте клиент-сервер задача обеспечения безопасности данных сводится к тому, что доступ к данным «1С:Предприятия» должен осуществляться только механизмами «1С:Предприятия». В связи с этим можно выделить несколько областей обеспечения безопасности.

Рис. 11. Общая схема безопасности

Все клиентские приложения и внешние соединения используют данные «1С:Предприятия» только через кластер серверов «1С:Предприятия», выполнив процедуру аутентификации «1С:Предприятия», заключающуюся в том, что перед началом работы с кластером серверов приложение должно сообщить ему имя пользователя системы «1С:Предприятие» и его пароль. Дальнейшая работа с кластером серверов будет возможной, только если пользователь с соответствующим паролем был зарегистрирован в информационной базе.

Данные, с которыми работает кластер серверов «1С:Предприятия», делятся на информационную базу и служебные данные. Таким образом, задача кластера серверов заключается в том, чтобы обеспечить безопасность данных в следующих областях (нумерацию областей см. рис. 11):

● при обмене между клиентом и кластером серверов (1);

● при обмене между консолью кластера серверов и кластером (2);

● при обмене данными между кластером серверов и веб-сервером (7);

● при хранении служебных данных в кластере серверов (3);

● при обмене данными внутри кластера (4).

Информационная база размещается в базе данных, и ее безопасность, а также безопасность при обмене между кластером серверов и сервером баз данных обеспечивается средствами используемой СУБД (5).

При подключении к информационной базе через веб-сервер безопасность обмена данными между клиентским приложением и веб-сервером обеспечивает используемый веб-сервер (6).

Безопасность данных, передаваемых между клиентом и кластером серверов, обеспечивается за счет возможности шифрования этих данных. При этом может быть выбран один из трех уровней безопасности:

● выключено,

● только соединение,

● постоянно.

Уровень выключено является самым низким, уровень постоянно – самым высоким. При этом используется безопасное соединение по протоколу TCP/IP с шифрованием алгоритмами RSA и Triple DES.

Использование уровня безопасности постоянно позволяет полностью защитить весь поток данных (как пароли, так и непосредственно данные) между клиентом и кластером серверов.

ВНИМАНИЕ! Следует учитывать, что при этом возможно значительное снижение производительности системы.

В общем виде протокол взаимодействия клиента и кластера серверов представлен на следующем рисунке.

Рис. 12. Уровень безопасности «постоянно»

Протокол взаимодействия одинаков как для менеджера кластера (rmngr), так и для рабочего процесса (rphost): после установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA, дальнейший обмен данными выполняется с использованием шифрования по алгоритму Triple DES.

Уровень безопасности задается при создании информационной базы. Эта информация сохраняется как на клиенте (в списке информационных баз), так и в кластере серверов (в реестре сервера). После создания информационной базы, установленный для нее уровень безопасности изменить уже нельзя. Уровень безопасности может быть повышен по инициативе клиентского приложения.

Поэтому после установки соединения клиент генерирует приватный и публичный ключи для шифрования RSA и передает в кластер серверов публичный ключ и уровень безопасности, который указан для данной информационной базы на клиенте. Это желаемый уровень безопасности.

Кластер серверов выбирает максимальный уровень безопасности из переданного клиентом и указанного для этой информационной базы в реестре кластера. Это фактический уровень безопасности. Кроме этого, кластер серверов генерирует сеансовый ключ для шифрования Triple DES и вместе с фактическим уровнем безопасности передает его клиенту, предварительно зашифровав эти данные с помощью публичного ключа клиента.

Дальнейший обмен данными выполняется в соответствии с фактическим уровнем безопасности, при этом как клиент, так и сервер шифруют передаваемые данные с использованием сеансового ключа по алгоритму Triple DES.

Использование уровня безопасности только соединение позволяет частично защитить поток данных (только пароли) между клиентом и кластером серверов. Этот уровень безопасности является компромиссом между безопасностью и производительностью.

С одной стороны, данные информационной базы передаются в открытом виде. Поскольку эти данные составляют основную массу всего потока данных, производительность системы практически не снижается.

С другой стороны, ключевая информация (пароли) передается только в зашифрованном виде. В результате если этот поток данных будет перехвачен, из него можно будет получить лишь незначительную часть данных информационной базы. Т. к. пароли будут недоступны, злоумышленник не сможет аутентифицироваться в информационной базе и получить доступ ко всем данным или выполнить произвольные действия с информационной базой.

В общем виде протокол взаимодействия клиента и кластера серверов представлен на рис.13.

Рис. 13. Уровень безопасности «только соединение»

После установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA, затем обмен данными выполняется с использованием шифрования по алгоритму Triple DES до окончания процедуры аутентификации. Дальнейший обмен выполняется нешифрованными данными.

Уровень безопасности выключено является самым низким и самым производительным. Практически все данные передаются без использования шифрования.

В общем виде протокол взаимодействия клиента и кластера серверов представлен на следующем рисунке.

Рис. 14. Уровень безопасности «выключено»

После установки соединения первый обмен данными выполняется с использованием шифрования по алгоритму RSA. Дальнейший обмен выполняется нешифрованными данными.

Если клиентское приложение и кластер серверов расположены на одном компьютере и уровень безопасности установлен в значение выключено, то шифрование данных между клиентским приложением и кластером серверов вообще не производится.

Безопасность данных, передаваемых между консолью кластера серверов и кластером серверов, обеспечивается также за счет возможности шифрования передаваемых данных. При этом используются те же самые три уровня безопасности: выключено, только соединение и постоянно.

Консоль кластера серверов взаимодействует с агентом сервера (процесс ragent). Желаемый уровень безопасности задается при старте агента сервера. Фактический уровень безопасности будет выбран агентом сервера как максимальный из указанного при старте и из уровней безопасности всех кластеров, расположенных на данном центральном сервере. Уровень безопасности кластера задается при его создании (программном или интерактивном).

Кластер серверов использует ряд служебных данных, например, список кластеров сервера, реестры кластеров и др. Все служебные данные представляют собой совокупность файлов, которые находятся в двух каталогах:

● каталог данных приложения,

● каталог временных файлов.

Общая идеология работы со служебными данными заключается в том, что доступ к служебным данным кластера серверов должны иметь только менеджер кластера (rmngr) и агент сервера (ragent). Рабочие процессы (rphost) используют служебные данные только через менеджера кластера, поскольку являются потенциально опасными, т. к. в них могут выполняться фрагменты кода конфигураций.

В каталоге данных приложения при установке кластера серверов «1С:Предприятия» создается специальный каталог, предназначенный только для файлов кластера серверов «1С:Предприятия».

Рис. 15. Каталог данных приложения

Пользователю USR1CV8, от имени которого стартует по умолчанию агент сервера, назначаются полные права на этот каталог. Другим пользователям доступ в этот каталог запрещается. Запуск менеджера кластера выполняет агент сервера от имени того же самого пользователя, от которого запущен он сам.

Пользователь USR1CV8 обладает правами:

● Вход в качестве службы (Log on as a service),

● Вход в качестве пакетного задания (Log on as a batch job).

Пользователь USR1CV8 должен входить в группы:

● Пользователи журналов производительности (Performance Log Users).

Запуск рабочих процессов также осуществляет агент сервера. По умолчанию рабочий процесс запускается от имени того пользователя, от которого запущен агент сервера. Однако предусмотрена возможность создания дополнительного пользователя операционной системы, от имени которого стартуют только рабочие процессы. Это позволяет предотвратить непосредственный доступ программного кода конфигураций к служебным данным.

Для того чтобы рабочий процесс запускался не от имени того же пользователя, что и агент сервера, в каталоге данных приложений, относящемся к пользователю агента сервера, может быть размещен файл swpuser.ini. Описание этого файла см. здесь.

Защита данных из временных файлов выполняется иначе. Поскольку системный каталог временных файлов является общедоступным, то в нем ограничиваются права доступа к каждому временному файлу отдельно.

Для этого при создании временного файла кластером серверов «1С:Предприятия» пользователю USR1CV8 устанавливаются полные права на создаваемый файл. Другим пользователям доступ к этому файлу запрещается. Таким образом, данные, хранимые во временных файлах, защищаются от несанкционированного доступа.

Рис. 16. Ограничение доступа

Пароли администраторов кластера серверов и пароли доступа к информационным базам хранятся в кластере серверов в зашифрованном виде. Для этого используется шифрование алгоритмами SHA1 и AES128:

● SHA1 – с его помощью хранятся пароли, которые проверяет система «1С:Предприятие» (например, пароль администратора кластера, администратора центрального сервера). При этом исходный текст хранимых паролей восстановить нельзя, а можно только проверить совпадение контрольной суммы введенного пароля с хранимой контрольной суммой.

● AES128 – с его помощью хранятся пароли, для которых должен восстанавливаться исходный текст (например, пароли доступа к СУБД).

Безопасность данных, передаваемых внутри кластера серверов (например, между рабочими процессами и менеджером кластера), обеспечивается за счет возможности шифрования передаваемых данных. При этом используются три уровня безопасности, о которых было сказано выше: выключено, только соединение и постоянно.

При взаимодействии рабочего процесса с менеджером кластера используется уровень безопасности кластера. При взаимодействии агента сервера с менеджером кластера уровень безопасности выбирается как максимальный из уровня безопасности, с которым запущен агент сервера, и уровня безопасности кластера, обслуживаемого данным менеджером.

Защита канала между кластером серверов и СУБД осуществляется средствами той СУБД, которая используется. Все поддерживаемые СУБД позволяют настроить свои клиентские компоненты, находящиеся в кластере, так, чтобы трафик между ними и самой СУБД был зашифрован. Все поддерживаемые СУБД могут использовать протокол SSL.

Для защиты канала между веб-клиентом и веб-сервером или между тонким клиентом и веб-сервером используются криптографические протоколы SSL или TLS.

Поддержку этих протоколов обеспечивает HTTPS-соединение с веб-сервером. Для этого на сервере должен находиться действительный серверный сертификат, который гарантирует клиенту подлинность открытого ключа сервера, используемого для шифрования данных. Также можно использовать клиентские сертификаты, гарантирующие серверу подлинность клиента.

Следует помнить об ограничениях, связанных с операционной системой, под которой работает клиентское приложение: в клиентском приложении, работающим под ОС Linux, не поддерживается использование клиентских сертификатов из хранилища сертификатов Windows.

Для защиты каналов между кластером серверов и веб-сервером используются алгоритмы шифрования данных, реализуемые системой «1С:Предприятие»: RSA и Triple DES.

Соединение между кластером и веб-сервером защищается только кластером на основании свойств информационной базы, к которой выполняется подключение (подробнее см. здесь).

Администрирование кластера серверов «1С:Предприятия» может выполняться как с использованием аутентификации администраторов, так и без нее.

Если аутентификация не используется, то любой пользователь, подключившийся к центральному серверу кластера, может выполнять все административные действия как с центральным сервером, так и с любым кластером, расположенным на данном сервере. По умолчанию после установки кластера серверов «1С:Предприятия» аутентификация администраторов не используется.

Для ограничения круга пользователей, которые могут выполнять административные действия, создаются списки администраторов центрального сервера (см. здесь) и списки администраторов каждого из кластеров (см. здесь), расположенных на данном сервере. Области действий, на которые распространяются права администраторов центрального сервера и администраторов кластеров, не пересекаются.

Аутентификация администратора центрального сервера позволяет пользователю выполнять административные действия с центральным сервером. Но для того, чтобы выполнить какие-либо административные действия с конкретным кластером, требуется аутентификация администратора кластера. В то же время для выполнения административных действий с кластером пользователь должен аутентифицироваться как администратор кластера; дополнительная аутентификация в качестве администратора сервера для этого не требуется.

Механизм аутентификации администраторов центрального сервера/кластера включается системой автоматически, как только в списке администраторов центрального сервера/кластера создается хотя бы один администратор.

При включенном механизме аутентификации пользователь, не аутентифицировавшийся как администратор центрального сервера, может только просмотреть и изменить параметры подключения к центральному серверу в консоли администрирования кластера серверов.

Пользователь, не аутентифицировавшийся в качестве администратора кластера, может только просмотреть свойства кластера. Кроме того, используя средства встроенного языка, такой пользователь может создавать объекты кластера, информационной базы и пр., но не имеет возможности регистрировать их в кластере.

Для обеспечения согласованной работы с информационной базой «1С:Предприятие» использует механизм блокировок, который обеспечивает конкурентную работу с тремя составляющими:

● конфигурация,

● информационная база,

● база данных.

Работу этого механизма можно увидеть в утилите администрирования кластера серверов (см. здесь).

Существуют два вида блокировок: разделяемая и исключительная. Разделяемые блокировки обеспечивают совместную работу нескольких сеансов. Исключительная блокировка используется в тех случаях, когда необходимо исключить возможность изменения данных другими сеансами.

С точки зрения администрирования системы важно знать, в каких случаях устанавливается исключительная блокировка (монопольный режим). При этом исключительная блокировка на конфигурацию и информационную базу устанавливается и снимается автоматически самой системой в некоторых случаях (см. ниже). Исключительная блокировка на базу данных может быть установлена или снята как автоматически системой, так и разработчиком при вызове метода встроенного языка УстановитьМонопольныйРежим().

При этом важно понимать, что данные блокировки относятся к механизмам «1С:Предприятия», которые отвечают за доступ к базе данных. Поэтому, например, установка исключительной блокировки базы данных не препятствует доступу к базе данных другим приложениям, не использующим механизмы «1С:Предприятия» для работы с базой данных.

Исключительная блокировка:

● На конфигурацию – устанавливается системой при запуске конфигуратора и гарантирует невозможность подключения к одной информационной базе нескольких конфигураторов.

● На информационную базу – означает, что может существовать только один сеанс любого вида. Блокировка устанавливается:

● При обновлении конфигурации базы данных;

● Загрузке информационной базы;

● Выгрузке информационной базы;

● Создании начального образа информационной базы;

● Конвертации информационной базы для новой версии платформы;

● Тестировании и исправлении.

● На базу данных – означает, что может существовать один сеанс вида Конфигуратор и только один дополнительный сеанс произвольного вида. Блокировка устанавливается:

● При выполнении метода УстановитьМонопольныйРежим() – требуется в тех случаях, когда необходимо выполнить согласованные изменения базы данных, но проводимые изменения не могут быть выполнены в одной транзакции. Например, при массовом удалении объектов в большой информационной базе.

● При групповом проведении документов (только для толстого клиента).

Если в момент попытки перехода в монопольный режим существуют служебные соединения с информационной базой, то такие соединения не препятствуют установке монопольного режима доступа (как к информационной базе, так и к базе данных).

Т. к. сеанс определяет активного пользователя, то наличие сеансов будет мешать переходу в монопольный режим (исключая сеанс консоли кластера). Кроме того, при попытке перехода в монопольный режим происходит неявный разрыв всех соединений с информационной базой, которым не назначен сеанс. Если установлен монопольный режим доступа к информационной базе или базе данных, то новые сеансы не могут быть начаты.

Если существуют веб-серверы, имеющие соединения с данной информационной базой, то при попытке установки монопольного доступа происходит обращение к этим серверам с целью очистки пула соединений.

Для каждого рабочего процесса кластер серверов вычисляет ряд параметров, которые характеризуют загруженность рабочего процесса. Все эти параметры вычисляются за период времени, равный примерно 10 минутам:

● среднее время реакции кластера серверов;

● среднее время, затраченное кластером серверов;

● среднее время, затраченное СУБД;

● среднее время, затраченное клиентом;

● среднее время, затраченное менеджером блокировок;

● среднее количество клиентских потоков.

Среднее время реакции кластера серверов представляет собой время, которое кластер серверов затратил на обслуживание одного клиентского соединения. Это время складывается из четырех составляющих:

● время, затраченное рабочим процессом;

● время, затраченное СУБД;

● время, затраченное самим клиентом (если управление передавалось обратно на клиента);

● время, затраченное менеджером блокировок.

Обслуживание каждого клиентского соединения рабочий процесс выполняет в отдельном потоке. Таким образом, в некоторый момент времени рабочий процесс может выполнять несколько клиентских потоков, количество которых, как правило, меньше количества соединений (т. к. не все соединения активны постоянно). Среднее количество клиентских потоков как раз и показывает среднее (за сутки) количество потоков, выполняемых рабочим процессом одновременно.

При работе кластера серверов необходимо отслеживать работоспособность отдельных элементов кластера и своевременно реагировать на проблемы. Для этого в составе кластера серверов существует подсистема мониторинга кластера. Эта подсистема выполняет регулярный сбор информации о состоянии процессов кластера. Под термином «процесс» в общем случае понимается любой компонент кластера серверов: агент сервера (ragent), менеджер сервера (rmngr), рабочий процесс (rphost). В том случае, если термин «процесс» не может быть однозначно использован в конкретном месте, он будет уточняться. В качестве собираемых (и анализируемых) показателей выступают:

● Проверка соединения с процессом.

● Вычисление доступной производительности рабочего процесса (см. здесь).

● Проверка объема памяти занимаемой процессом (применимо для менеджера кластера и рабочего процесса).

● Анализ отношения количества ошибок к количеству запросов или, другими словами, среднее, за последние 5 минут, отношение количества событий типа EXCP к количеству сообщений типа CALL в технологическом журнале.

● Отслеживание рабочих процессов удаленных из реестра кластера.

Некоторые операции (например, проверка объема памяти, занятой процессом) выполняются через соответствующие агенты серверов, тем самым проверяя работоспособность этих агентов.

Проверка производится каждые 10 секунд. Таймаут при проверке соединения составляет 20 секунд. Проверки выполняются последовательно, каждая следующая проверка не начнется до окончания предыдущей проверки. Отрицательные результаты проверки фиксируются в технологическом журнале, с помощью события ATTN.

В том случае, если в результате анализа собранных показателей процесс признается проблемным (из анализа исключается показатель доступной производительности), то возможно принудительное завершение проблемного процесса (с формированием дампа аварийного завершения). Принудительное завершение (и формирование дампа аварийного завершения) выполняется в том случае, если в свойства кластера установлен флажок Принудительно завершать проблемные процессы. Процессы на дополнительных серверах завершаются с помощью запросов к соответствующим агентам кластера.

Создание дампов аварийного завершения выполняется по общим правилам создания дампов в платформе «1С:Предприятие»:

● Для ОС Windows используются настройки из файла logcfg.xml;

● Для ОС Linux используются настройки ОС, а начало записи дампа аварийного завершения выполняется путем отправки процессу сигнала SIGSEGV.

Подробнее о настройке формирования дампов аварийного завершения см. здесь.

Опрос процессов кластера производит только агент центрального сервера. При опросе процессов на дополнительных рабочих серверах используются агенты дополнительных серверов. В случае ошибки соединения с агентом сервера, в технологическом журнале агента центрального сервера появляются сообщения об ошибках.

В процессе работы кластера серверов регулярно выполняются серверные вызовы (отражаемые в технологическом журнале событием CALL). Во время исполнения этих вызовов могут происходить различные ошибки (в технологическом журнале отражаются событием EXCP). Факт фиксации в технологическом журнале события EXCP не означает, что произошла реальная проблема в работе сервера. Например, при выборе рабочего порта из доступного диапазона, каждый занятый порт фиксируется в сообщении EXCP, но сама по себе ситуация не является проблемной, т. к. будет выполняться поиск следующего порта и так далее. В общем случае, отношение количества ошибок к количеству серверных вызовов является стабильным значением. Но может возникнуть ситуация, когда из-за внутренних проблем рабочий сервер начинает генерировать количество ошибок, которое превышает среднее количество для данной конфигурации сервера. Для обнаружения таких ситуация существует свойство Допустимое отклонение количества ошибок сервера. Данное свойство указывает, какое отклонение в количестве ошибок (в %) от среднего показателя по рабочим процессам данного кластера серверов является подозрительным и может свидетельствовать о наличии проблем. Если рабочий процесс считает проблемным, то он завершается (с формированием дампа аварийного завершения) и записью события ATTN в технологический журнал. Завершение проблемного рабочего процесса выполняется только в том случае, если в свойствах кластера установлен флажок Принудительно завершать проблемные процессы. Если значение свойства Допустимое отклонение количества ошибок сервера равно 0, то проверка отклонения количества ошибок не выполняется.

Вне зависимости от установленного значения свойства Допустимое отклонение количества ошибок сервера, рабочий процесс, который совершает не более 1 ошибки на 100 запросов, считает функционирующим нормально и не признается проблемным.

Рассмотрим пример работы свойства Допустимое отклонение количества ошибок сервера. Допустим, на 100 запросов фиксируется, в среднем, 2 ошибки за последние 5 минут. Если свойство Допустимое отклонение количества ошибок сервера установлено в значение 50, то проблемным будет считаться тот рабочий процесс, для которого будет фиксироваться более 3 ошибок на 100 запросов.

Для оценки текущего количества ошибок и вызовов сервера, следует включить запись в технологический журнал событий EXCP и CALL, затем проработать в системе более 5 минут и любым доступным способом получить количество событий каждого типа для каждого рабочего процесса.

При отслеживании процессов удаленных из реестра кластера, процесс признан проблемным, если он не завершился в течение 20 минут после удаления из реестра кластера.

Описанную систему мониторинга кластера серверов может помочь при решении следующих проблем:

● «Зависание» процесса сервера в памяти процессов компьютера как в процессе работы, так и во время попытки завершения процесса.

● Превышение каким-либо рабочим сервером среднего количества ошибок и, как следствие, нарушение нормального функционирование рабочего процесса.

● Неактуальная информация о памяти, занимаемой рабочим процессом, которая отображается в консоли кластера.

● Повышенное потребление памяти менеджером кластера.

Если при установке системы «1С:Предприятие» был выбран вариант запуска сервера «1С:Предприятия» как сервиса, то первый запуск агента сервера будет выполнен еще в процессе установки системы. При этом сервис будет запущен от имени пользователя, выбранного в диалоге установки системы, но служебные файлы кластера серверов будут расположены в каталоге <каталог установки системы 1С:Предприятие>\srvinfo (в параметрах сервиса будет в явном виде указан ключ запуска /d).

Если при установке системы «1С:Предприятие» был выбран вариант запуска сервера как приложения, то запуск сервера в процессе установки системы не выполняется; агента сервера необходимо запустить самостоятельно, после того как установка системы будет закончена. При этом если ключ запуска /d указан не будет, служебные файлы кластера серверов будут расположены в каталоге по умолчанию: %USERPROFILE%\Local Settings\Application Data\1C\1cv8 (%LOCALAPPDATA%\1C\1cv8 для ОС Windows Vista и старше).

ВНИМАНИЕ! Если однажды на данном центральном сервере уже был создан кластер, то при смене варианта запуска агента сервера (сервис, приложение) или при смене пользователя, от имени которого работает агент сервера, всегда следует заботиться о правильном указании пути к каталогу служебных файлов кластера серверов. Если в процессе запуска агент сервера не обнаружит список кластеров, он создаст новый кластер на данном сервере.

В операционной системе Linux служебные файлы кластера серверов будут расположены в папке /home/usr1cv8/.1cv8/1C/1cv8 (или сокращенный вариант записи – ~/.1cv8/1C/1cv8).

При работе кластера серверов «1С:Предприятия» на компьютерах под управлением операционной системы Linux существуют следующие ограничения:

● Рабочий процесс кластера серверов «1С:Предприятия» не может взаимодействовать с СУБД Microsoft SQL Server.

● Рабочий процесс кластера серверов «1С:Предприятия» не может взаимодействовать с COM-объектами. Допускается компиляция серверных модулей, осуществляющих работу с COM-объектами, однако при попытке выполнения такого модуля будет выдано сообщение об ошибке.

● Аутентификация выполняется на основе Kerberos (Windows версия поддерживает протокол NTLM, который способен, в частности, обеспечить аутентификацию без PDC) и/или имени и пароля пользователя.

● Недоступна функциональность объекта ИнтернетСоединение.

Для использования некоторых возможностей на сервере «1С:Предприятия», запущенного под управлением ОС Linux, необходимо наличие некоторых библиотек. Перечень необходимых библиотек и возможности, при использовании которых эти библиотеки необходимы, см. здесь.